Methods and Systems for Performing Remote Diagnostics

ABSTRACT

Diagnostic methods and systems are described in which a client or consumer electronic device can be remotely controlled and operated for purposes which include performing diagnostics and/or implementing remedial measures designed to remedy identified problems associated with the consumer electronic device.

RELATED APPLICATION

This application is a continuation of, and claims priority to, U.S.patent application Ser. No. 11/092,152 to Nichols et al., entitled,“Methods and Systems for Performing Remote Diagnostics”, filed on Mar.29, 2005 and issued under U.S. Pat. No. 7,716,316, which is incorporatedherein by reference.

BACKGROUND

Current remote diagnostic support efforts for consumer electronicdevices typically require a product support representative to instruct acustomer to perform series of commands with an input device, such as aremote control device, to attempt to test and diagnose a particularproblem. This can and usually does take place over the telephone, withthe customer and the support representative exchanging informationduring their conversation.

Needless to say, this approach is a fairly inefficient way to attempt todiscover and remedy problems associated with the device. For example,this solution typically requires a one-to-one relationship between thecustomer and the support representative. In addition, this solution doesnot scale very well in the event a large number of customers experienceproblems at the same time, or experience problems having a similarnature.

Accordingly, this invention arose out of concerns associated withproviding improved diagnostics and customer care.

SUMMARY

Diagnostic methods and systems are described in which a client orconsumer electronic device can be remotely controlled and operated forpurposes which include performing diagnostics and/or implementingremedial measures designed to remedy identified problems associated withthe consumer electronic device.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows an exemplary system in which various inventive principlescan be employed, in accordance with one embodiment.

FIG. 2 illustrates an exemplary consumer electronic device, inaccordance with one embodiment.

FIG. 3 is a flow diagram that describes steps in a method in accordancewith one embodiment.

FIG. 4 illustrates an exemplary entertainment and information system inwhich an IP-based television environment can be implemented, inaccordance with one embodiment.

DETAILED DESCRIPTION

Diagnostic methods and systems are described in which a client orconsumer electronic device can be remotely controlled and operated forpurposes which include performing diagnostics and/or implementingremedial measures designed to remedy identified problems associated withthe consumer electronic device.

In at least one embodiment, the consumer electronic device takes theform of an Internet Protocol (IP)-enabled client, such as an IP-enabled,television-based client, in which the client can be controlled utilizingso-called virtual keystrokes. Specifically, in one embodiment, theclient device can be remotely controlled by a web service that islocated at an associated system headend.

The web service can send batches of commands, actions or events, ascustom scripts or pre-created scripts to the client. In one embodiment,the commands can be sent in extensible markup language (XML) form. Theclient receives and parses these scripts and executes any commands,actions or events contained in the scripts. The client can then sendback information to the web service about the results of the execution.

Typically, in the context of an IP-enabled television-based client, atleast some of these commands can take the form of virtual key strokesthat simulate presses on a remote control associated with the client.The client processes these virtual key strokes as if they were sent bythe remote control and accordingly, allows the web service to manipulatethe client device. Other commands can be sent as well, such as thosethat are utilized to obtain real time status from the client such memoryusage, error conditions, or other diagnostic information.

In at least some embodiments, by enabling automated remote real timediagnostics of the consumer electronic device clients, product supportrepresentatives can quickly diagnose individual problems, as well asproblems affecting a large number of clients.

Exemplary Embodiment Overview

FIG. 1 shows an exemplary system in accordance with one embodiment,generally at 100. In this example, system 100 includes one or moreconsumer electronic devices 102, individuals ones of which comprisecomputer-readable media 104 (examples of which are given below). Inaccordance with one embodiment, diagnostic code 106 is embodied on thecomputer-readable media and is executable by one or more processors 108,as described below, to enable the consumer electronic device to initiatecontact with a remote diagnostic entity and then, responsive to theinitiated contact, be remotely controlled and operated for purposeswhich include, by way of example and not limitation, performingdiagnostics and/or implementing remedial measures designed to remedyproblems associated with the consumer electronic device.

In the illustrated and described example, the consumer electronic deviceis communicatively linked with a network 110 for communication with adiagnostic center, indicated generally at 112. Network 110 can compriseany suitable network. In at least one embodiment, network 110 comprisesa broadband IP-based network and communication with diagnostic center112 takes place via IP-based methods and techniques.

In at least one embodiment, diagnostic center 112 comprises, among othercomponents, a diagnostic entity. In this particular example, thediagnostic entity comprises a bootstrap server 114, a diagnostic server116 embodying a web application 118 that can provide an interface to acustomer service representative, and a database 120. Although thebootstrap and diagnostic servers 114, 116 are depicted as separateentities, such need not be the case.

In at least some embodiments, communication with the diagnostic centeris initiated by the client in what can be considered as a pull-typemodel. In these embodiments, the client first contacts the diagnosticcenter to ascertain whether there are any diagnostics that should or canbe run. In this manner, a degree of security is provided because it isthe client that first initiates contact, and not the diagnostic centeror some other third party. Specifically, in these embodiments, theclient first contacts the diagnostic center to initiate a diagnosticsession. Subsequent information exchange between the client and thediagnostic center then takes place responsive to the client-initiatedcontact.

In at least some embodiments, the communication that takes place betweenthe consumer electronic device 102 and servers 114, 116 is secure. Forexample, the communication between these entities can be encrypted usingany suitable technique such as public/private key pairs, and the like.In addition, in one embodiment, communication between the consumerelectronic device 102 and servers 114, 116 takes place utilizingextensible markup language (XML). But one example of an XML schema thatcan be utilized to facilitate communication is provided below under theheading “Exemplary XML Schema”.

In operation in accordance with one embodiment, when consumer electronicdevice 102 is activated or otherwise booted up (or at other times as maybe appropriate), diagnostic code 106 executes to contact the bootstrapserver 114, via network 110, to attempt to locate one or more diagnosticservers. In this example, a bootstrap web service executing on thebootstrap server 114 can maintain a list of diagnostic servers, as wellas information that can be utilized to contact a diagnostic server. Suchinformation can include, by way of example and not limitation, a URI orother web address that can be utilized to locate and contact thediagnostic server.

In the event that the bootstrap service has the appropriate informationavailable for contacting the diagnostic server, it can return to theconsumer electronic device with that information so that the device canattempt to contact and initiate a session with the appropriatediagnostic server. However, in the event the bootstrap service does nothave the appropriate information available, diagnostic code 106 canterminate execution.

By terminating execution responsive to the bootstrap service not havingthe appropriate contact information available for contacting thediagnostic server, a first security gate is provided. Specifically, inthis particular embodiment, if the information that is utilized tocontact the appropriate diagnostic server is unavailable, then thediagnostic code terminates which, in turn, eliminates access to thefunctionality that can be used to remotely control and operate theconsumer electronic device.

Assume, however, that the bootstrap server 114 returns to the consumerelectronic device 102 with the appropriate contact information. In thiscase, the consumer electronic device's diagnostic code 106 can attemptto contact the diagnostic server 116 and an associated diagnosticservice to initialize a session. If, for whatever reason, device 102 isunable to initiate a session once the diagnostic server is contacted(e.g., perhaps the diagnostic service is unavailable), the diagnosticcode 106 can terminate execution which, in turn, provides a secondsecurity gate similar to the one mentioned just above.

In the event that device 102 is able to initiate a session withdiagnostic server 116, the device can begin to contact the diagnosticservice to ascertain whether there are any commands, events or actionsthat it is to execute and/or report.

In one embodiment, database 120 maintains information that can include alist of clients, client sessions, client statistics and the like. Inaddition, database 120 can maintain a list scripts, events and commandsthat can be sent to the consumer electronic device for execution.Accordingly, the diagnostic server can use the database to identify andinitialize clients, start and track diagnostic sessions, identifyappropriate scripts to be sent to appropriate clients, and maintain dataassociated with client execution of the scripts.

Continuing, responsive to having a session initiated by a consumerelectronic device, the diagnostic server 116 can, based on the sessionand the particular device, distribute commands, events or actions to thedevice for execution.

Responsive to receiving the distributed commands, events or actions, theconsumer electronic device 102 can perform the commands or otherwisetake the appropriate actions, and can return associated information tothe diagnostic service reporting the status of the performed actions orcommands, such as whether actions were (un)successfully performed,whether any exceptions were encountered and the like. Accordingly, thisreturned information provides the diagnostic server 116 with contextassociated with the commands, events or actions that it previouslydistributed to the consumer electronic device. The diagnostic server canthen enter and maintain that information in database 120.

Implementation Example—Exemplary Consumer Electronic Device

FIG. 2 illustrates various components of an exemplary consumerelectronic device or client 200 in accordance with one embodiment.Device 200 can be implemented as any form of computing or electronicdevice with any number and combination of differing components.

In this example, computing device or client 200 includes one or moremedia content inputs 202 which may include Internet Protocol (IP) inputsover which streams of media content are received via an IP-basednetwork. In various embodiments, device 200 can be implemented as anIP-enabled television-based client in an IP-enabled televisionenvironment.

Device 200 further includes communication interface(s) 204 which can beimplemented as any of one or more of a serial and/or parallel interface,a wireless interface, any type of network interface, a modem, and as anyother type of communication interface. A wireless interface enablesdevice 200 to receive control input commands 206 and other informationfrom an input device, such as from remote control device 208, PDA(personal digital assistant) 210, a cellular phone, or from otherinfrared (IR), 802.11, Bluetooth, or similar RF input devices.

In one embodiment, the commands, actions or events that are sent by thediagnostic server allow the diagnostic server to remotely provide input,such as virtual keystrokes like remote control button input, to device200.

A network interface provides a connection between device 200 and acommunication network (e.g., network 110 shown in FIG. 1) by which otherelectronic and computing devices (such as bootstrap server 114 anddiagnostic server 116) can communicate data with device 200. Similarly,a serial and/or parallel interface provides for data communicationdirectly between device 200 and the other electronic or computingdevices. A modem facilitates device 200 communication with otherelectronic and computing devices via a conventional telephone line, aDSL connection, cable, and/or other type of connection.

Client device 200 also includes one or more processors 212 (e.g., any ofmicroprocessors, controllers, and the like) which process variouscomputer executable instructions to control the operation of device 200,to communicate with other electronic and computing devices, and toimplement embodiments of the diagnostic system described above andbelow. Device 200 can be implemented with computer readable media 214,such as one or more memory components, examples of which include randomaccess memory (RAM), non-volatile memory (e.g., any one or more of aread-only memory (ROM), flash memory, EPROM, EEPROM, etc.), and a diskstorage device. A disk storage device can include any type of magneticor optical storage device, such as a hard disk drive, a recordableand/or rewriteable compact disc (CD), a DVD, a DVD+RW, and the like.

Computer readable media 214 provides data storage mechanisms to storevarious information and/or data such as software applications and anyother types of information and data related to operational aspects ofthe computing and/or client device 200. For example, an operating system216 and/or other application programs 218 can be maintained as softwareapplications with the computer readable media 214 and executed onprocessor(s) 212 to implement embodiments of the diagnostic system.Computer readable media 214 also maintains diagnostic code 220 thatimplements embodiments of the diagnostic system described above andbelow.

Although the diagnostic code 220 is illustrated and described as asingle application configured to implement embodiments of the diagnosticsystem, the diagnostic code can be implemented as several componentapplications distributed to each perform one or more functions in aclient device.

In this particular example, device 200 is implemented as an IP-enabledtelevision-based client and computer readable media 214 includes aprogram guide application 222. Program guide application 222 processesprogram guide data 224 and generates program guides for display which,in turn, enable a viewer to navigate through an onscreen display andlocate broadcast programs, recorded programs, video on-demand programsand movies, interactive game selections, and other media accessinformation or content of interest to the viewer.

Client device 200 also includes an audio and/or video output 226 thatprovides audio and video to an audio rendering and/or display system228, or to other devices that process, display, and/or otherwise renderaudio, video, and display data. Video signals and audio signals can becommunicated from device 200 to television 230 via an RF (radiofrequency) link, S-video link, composite video link, component videolink, analog audio connection, or other similar communication link.

Exemplary Method—Client Side and Server Side

FIG. 3 is a flow diagram that describes steps in a method in accordancewith one embodiment. The method can be implemented in connection withany suitable hardware, software, firmware or combination thereof. In atleast one embodiment, aspects of the method about to be described can beimplemented by a consumer electronic device, examples of which are givenabove. In addition, other aspects of the method can be implemented by asuitably configured server or servers, examples of which are given aboveas well.

In the method about to be described, the consumer electronic devicefirst attempts to initiate communication with a diagnostic entity. Inthe event that communication with the diagnostic entity is initiated,the device then attempts to initialize itself with the diagnosticentity. In the event that the device is initialized, it then contactsthe diagnostic entity to start a diagnostic session and receives, fromthe diagnostic entity and as part of the diagnostic session, at leastone command, event or action. The device then performs acts associatedwith the command(s), event(s) or action(s) and reports back to thediagnostic entity information associated with the performed acts.

In the specific example of FIG. 3, various aspects of the method arelisted under the designation “Consumer Electronic Device” to indicatewhich steps can be performed by a suitably configured consumerelectronic device. Likewise, other aspects of the method are listed,respectively, under the headings “Bootstrap Server” and “DiagnosticServer” to indicate which steps can be performed by which entity. It isto be appreciated and understood that the bootstrap server and thediagnostic server can collectively, in at least one embodiment,constitute a diagnostic entity. Other diagnostic entities can beutilized, however, without departing from the spirit and scope of theclaimed subject matter.

Accordingly, step 300 calls, via a suitably configured consumerelectronic device, a bootstrap method to ascertain a diagnostic serverlocation. This step can be performed by a suitably configured consumerelectronic device at any suitable time. For example, in at least someembodiments, this step can be performed by diagnostic code executing onthe device, in conjunction with the device's bootup or reset procedure.Alternately or additionally, this step can be performed at other times.

Step 302 receives, with the bootstrap server, the call from the consumerelectronic device. If diagnostic server location information isavailable, then step 304 provides this information to the consumerelectronic device. In the event this information is not available (asindicated by dashed box 304) or, in the event the initial call from theconsumer electronic device fails, the diagnostic code executing on theconsumer electronic device can terminate execution, thus providing afirst security gate. Any suitable diagnostic server location informationcan be used, such as a URI and the like.

If the diagnostic server location information is available and providedto the consumer electronic device, step 306 receives the information andstep 308, responsively, attempts to contact a diagnostic server usingthe diagnostic server location information. In addition, the consumerelectronic device attempts to initialize itself with the diagnosticserver. To initialize itself with the diagnostic server, the consumerelectronic device can pass a client ID, as well as client configurationinformation to the server.

Step 310 receives the call from the consumer electronic device and step312 may or may not initialize and return to the consumer electronicdevice. If the diagnostic server or, in at least some embodiments, a webservice executing on the diagnostic server, does not respond orinitialize the device, the diagnostic code executing on the consumerelectronic device can terminate, thus providing a second security gate.If, on the other hand, the diagnostic server does return or respond tothe consumer electronic device, it can return an indication that theelectronic device can begin requesting diagnostic sessions.

Accordingly, step 314 calls the diagnostic server to start a diagnosticsession. To do so, the consumer electronic device can pass in its clientID. Step 316 receives the session start call and, responsively, thediagnostic server can then take some preliminary actions, such asidentifying, based on the client ID, a particular group that the device(or its corresponding diagnostic code) may belong to and, based onconfiguration information contained in its database, return a session IDto the consumer electronic device.

Step 318 receives, via the consumer electronic device, the session IDand can begin making diagnostic server calls using the session ID toidentify the particular session to which it belongs. Step 320 receives,at the diagnostic server, the calls and session ID and, based on thesession ID, can begin to distribute commands, events or actions to theconsumer electronic device for remote execution. In one embodiment, thecommands, events or actions are distributed using XML, an example ofwhich is provided below.

Step 322 receives these commands, events or actions and step 324 takesthe appropriate action as by performing the commands, events or actions.Step 326 builds a report pertaining to the performed commands, events oractions and step 328 transmits the report to the diagnostic server. Inat least one embodiment, the report that is built is implemented as anXML report that contains context information associated with thedevice's performance of the commands, events or actions that it receivedfrom the server. One example of an XML report is provided below.

Step 330 receives the transmitted report and step 332 enters pertinentinformation in an appropriate database. By entering informationcontained in the report in a database and maintaining such information,the diagnostic server is able to keep a history of individual consumerelectronic devices. This can be useful for identifying trends not onlyassociated with individual devices, but across multiple devices as well.

In the context of consumer electronic devices that comprise IP-enableddevices, such as television-based client systems, examples of commands,events or actions that can be sent to the client include any form inputcontrol that might be provided by a user, such as a remote control input(e.g. channel up/down, volume up/down, EPG menu select) and the like.Alternately or additionally, such commands, events or actions maypertain to accessing contextual information about the client device,such as memory usage, various types of memory information, disk spaceand the like. In this manner, the diagnostic service and, morespecifically, a web service executing on the diagnostic server canremotely control and interact with a particular client device.

In application, the commands, event or actions that are sent from thediagnostic server can be pre-scripted. Alternately or additionally, thecommands, events or actions can be specifically constructed, as by acustomer service representative, to address a particular problem that auser may be experiencing with a specific client device. In this manner,customer service can be improved by freeing up the customer servicerepresentative from having to engage the customer in a lengthy sessionand having to ask the particular customer to press different keys andreport the results back over the telephone.

Implementation Example—Exemplary Entertainment and Information System

FIG. 4 illustrates an exemplary entertainment and information system 400in which an IP-enabled television-based client can be implemented inaccordance with one embodiment.

In the illustrated and described embodiment, system 400 facilitates thedistribution of program content and program guide data to multipleviewers and includes a content provider 402 and television-based clientsystems 404(1-N) each configured for communication via a network 406.The network 406 can be implemented as a wide area network (e.g., theInternet), an intranet, a Digital Subscriber Line (DSL) networkinfrastructure, or as a point-to-point coupling infrastructure.Additionally, network 406 can be implemented using any type of networktopology and any network communication protocol, and can be representedor otherwise implemented as a combination of two or more networks. Adigital network can include various hardwired and/or wireless links408(1-N), routers, gateways, and so on to facilitate communicationbetween content provider 402 and the client systems 404(1-N).

System 400 includes an acquisition server 410 that receives programcontent from a content source 412, and program guide data from a programguide source 414. The program guide data is used to generate anelectronic program guide for a viewer. The content source 412 and theprogram guide source 414 control distribution of the program content andthe program guide data to the acquisition server 410 via varioustransmission media 416, such as satellite transmission, radio frequencytransmission, cable transmission, and/or via any number of othertransmission media. In this example, acquisition server 410 is shown asan independent component of system 400 that communicates the programcontent and program guide data to content provider 402. In an alternateimplementation, acquisition server 410 can be implemented as a componentof content provider 402.

As used herein, “program(s)” and “program content” pertains to newsshows, sitcoms, comedies, movies, commercials, talk shows, sportingevents, on-demand videos, and any other form of television-basedentertainment and information. Further, “recorded programs” include anyof the aforementioned “programs” that have been recorded and that aremaintained with a memory component as recorded programs, or that aremaintained with a remote program data store. The “recorded programs” canalso include any of the aforementioned “programs” that have beenrecorded and that are maintained at a broadcast center and/or at aheadend that distributes the recorded programs to subscriber sites andto the client systems 404(1-N).

In addition, system 400 includes one or more bootstrap servers 418 andone or more diagnostic servers 420. Bootstrap server 418 can be utilizedto help establish a connection between a client device and a diagnosticserver, as described above. The diagnostic server 420 can be utilized tointerface with a client device, to provide commands, events and actionsto the client device, and to receive and record contextual informationassociated with a client device's execution or performance of thecommands, events and actions, as described above.

Content provider 402 is representative of a headend service in atelevision-based content distribution system, for example, that includesserver(s) to provide the program content and associated data, as well asprogram guide data, to multiple subscribers (e.g., the television-basedclient systems 404(1-N)). In addition, the headend service can includethe bootstrap and diagnostic servers 418, 420 respectively. The contentprovider 402 can be implemented as a satellite operator, a networktelevision operator, a cable operator, and the like to controldistribution of program content, such as movies, television programs,commercials, music, and other audio, video, and/or image content to theclient systems 404(1-N).

The television-based client systems 404(1-N) can be implemented with anynumber and combination of differing components, such as thoseillustrated and described above. In this example, the television-basedclient systems 404(1-N) can be implemented to include a client device200 and a display device 230 (e.g., a television) such as thosedescribed in FIG. 2. As will be appreciated by the skilled artisan,client device 200 can be implemented in any number of embodiments, suchas a set-top box, a digital video recorder (DVR) and playback system, apersonal video recorder (PVR), an appliance device, and as any othertype of client device that may be implemented in a television-basedentertainment and information system.

In addition, a client device 200 can be coupled to any number oftelevisions 230 and/or similar devices that can be implemented todisplay or otherwise render program content. Similarly, any number ofthe client devices 200 of the respective client systems 404(1-N) can becoupled to a single television 230. In an alternate embodiment, clientsystem 404(N) is implemented with a computing device 426 as well as aclient device 200.

Exemplary Database Schema

In one embodiment, the diagnostic server employs a particular databaseschema to assist it in organizing and managing the information that itutilizes in not only overseeing administration of the various diagnosticscenarios, but in managing information associated with the variousclients that might use its services.

In a specific embodiment, the database schema is used to organize andmanage information associated with various web services (such as thebootstrap service), client devices and configurations, groups to whichclient devices may belong, events and scripts (e.g. those used forgenerating diagnostic scenarios), diagnostic sessions (e.g. active andcompleted), and outcome results of the diagnostic sessions, to name justa few.

Exemplary XML Schema

As noted above, in at least one embodiment, extensible markup language(XML) is utilized to enable the consumer electronic device and thediagnostic server to articulate information back and forth. As but oneexample, consider the XML excerpt just below. In this example, the XMLdescribes a script, encapsulated by the <EventScript> tag, which isintended to be sent from the diagnostic server to one or more consumerelectronic devices. In this particular example, the script includes anumber of key activations (e.g. “back”, “channeldown”, etc), and anumber of commands (e.g. “GetDiskInfo” and “GetMemInfo”).

<?xml version=“1.0” encoding=“utf-8”?> <Monkey> <EventScriptResultID=‘35100746-213A-4B2E-BA8F-9B5754BACCBF’> <Event Type=“key”Inst=“back” Sleep=“500”/> <Event Type=“key” Inst=“channeldown”Sleep=“500”/> <Event Type=“key” Inst=“channelup” Sleep=“500”/> <EventType=“key” Inst=“down” Sleep=“500”/> <Event Type=“key” Inst=“ffwd”Sleep=“500”/> <Event Type=“cmd” Inst=“GetDiskInfo”/> <Event Type=“cmd”Inst=“GetMemInfo”/> </EventScript> </Monkey>

In this particular example, when the electronic device receives theabove-described XML, it parses the XML and begins to perform the eventsor commands. Upon completion of the script, the device can thenformulate a report or response for the diagnostic server. As but oneexample of a report, and one which is not necessarily related theabove-identified script, consider the XML excerpt just below.

<?xml version=“1.0” encoding=“utf-8”?> <Monkey> <ResponseResult=‘Passed’ ResultID=‘GUID’ Duration=‘3988.32’> <ContextName=“Disk”> <Entry Name=“Bytes Used”>1024</Entry> <Entry Name=“BytesAvailable”>2048</Entry> </Context> <Context Name=“Memory”> <EntryName=“Bytes Used”>1024</Entry> <Entry Name=“BytesAvailable”>2048</Entry> </Context> <ContextName=“ProcessManagement”><Entry Name=“Bytes Used”>1024</Entry> <Entry Name=“BytesAvailable”>2048</Entry> </Context> </Response> </Monkey>

Here, the report or response, encapsulated by the <Response> tag,provides contextual information back to the diagnostic server so thatthe server can evaluate and, if appropriate, save the relevantinformation. In this particular example, the response includesinformation that pertains to the device's disk and memory usage.

CONCLUSION

The above-described diagnostic methods and systems can enable a clientor consumer electronic device to be remotely controlled and operated forpurposes which include performing diagnostics and/or implementingremedial measures designed to remedy identified problems associated withthe consumer electronic device. In this manner, various embodiments canenhance the customer's experience by removing, in at least somescenarios, the requirement for the customer to be physically involvedduring the diagnostics. In addition, economies extend to customerservice representatives. Specifically, through the automatic, remotediagnostics functionality, individual problems can be quickly andautomatically identified. In addition, problems associated with largernumbers of client devices can be quickly and automatically identified.

Although the invention has been described in language specific tostructural features and/or methodological steps, it is to be understoodthat the invention defined in the appended claims is not necessarilylimited to the specific features or steps described. Rather, thespecific features and steps are disclosed as preferred forms ofimplementing the claimed invention.

1. A method comprising: receiving a first call from a consumerelectronic device to initiate contact with a remotely located diagnosticentity; initializing the consumer electronic device with the diagnosticentity; receiving a second call from the consumer electronic device tostart a diagnostic session; distributing at least one command, event oraction to the consumer electronic device for remote execution at theconsumer electronic device; and receiving a report from the consumerelectronic device that pertains to the device's performance of the atleast one command, event or action.
 2. A method of claim 1, wherein:receiving the first call includes receiving the first call with a firstserver; and receiving the second call includes receiving the second callwith a diagnostic server.
 3. A method of claim 1 further comprisingresponsive to receiving the second call, returning a session ID to theconsumer electronic device, wherein the session ID can be used insubsequent calls to the diagnostic entity.
 4. A method of claim 1further comprising responsive to receiving the second call, returning asession ID to the consumer electronic device, wherein the session ID canbe used in subsequent calls to the diagnostic entity, and wherein thedistributing is performed responsive to receiving a call from theconsumer electronic device that utilizes the session ID.
 5. A method ofclaim 1, wherein the distributing is performed, at least in part, bydistributing XML that describes the at least one command, event oraction.
 6. A method of claim 1, wherein the report is an XML report. 7.The method of claim 1, wherein the consumer electronic device comprisesan IP-enabled device.
 8. The method of claim 1, wherein the consumerelectronic device comprises an IP-enabled television-based client. 9.The method of claim 1, wherein the at least one command, event or actionpertains to execution of a virtual key stroke.